Release 0.6.0 #601
Release 0.6.0 #601
Conversation
Release v0.5.0
bump to 0.5.0+dev
This should never happen in normal use, but sometimes there are bugs that can cause the init task to crash. (For example, I hit this while trying to debug python-triogh-550.) Previously, this would trigger an assertion failure, and the original exception would be lost. Let's preserve the original exception to make debugging easier.
Add python 3.7 to the appveyor test matrix
This closes issue python-trio#548.
Travis MacOS is much more functional than it used to be, and on ci.cryptography.org we're hitting: MagicStack/immutables#7 So let's try turning on Travis's MacOS and see how it goes, while scaling back our Jenkins testing so that bug doesn't block everything.
Enable MacOS testing on Travis, disable 3.6 testing on Jenkins
Also an excuse to force the tests to re-run so I can merge this.
complete SSLListener doc
Fix CapacityLimiter memory leak.
While the Travis MacOS infrastructure is clearly *much* better than it used to be, doing these tests on Jenkins is still faster overall, and it avoids hitting python-triogh-584. This commit: - adds a temporary workaround for MagicStack/immutables#7 - re-enables all MacOS builds on Jenkins - including 3.7, which was previously not enabled - re-disables Travis MacOS builds
Switch back to Jenkins for MacOS builds
Try testing PyPy's 3.6 branch too
Fixed a small spelling mistake in the tutorial docs
Implement cancelable WaitForSingleObject for Windows
Fix variable names in docstring example for serve_tcp
Fix crash when used with Raven.
Codecov Report
@@ Coverage Diff @@
## release #601 +/- ##
===========================================
+ Coverage 99.27% 99.31% +0.04%
===========================================
Files 89 91 +2
Lines 10617 10822 +205
Branches 747 753 +6
===========================================
+ Hits 10540 10748 +208
+ Misses 59 56 -3
Partials 18 18
Continue to review full report at Codecov.
|
|
598 is already part of his. |
|
@smurfix That was my point, we included a commit in the release that has not been approved yet |
|
Remind me again if there's any reason for having a My inclination is to close this and delete the branch unless there's a good reason not to. |
|
I guess the main benefit is that you can easily see on GitHub all the commits that will make it into the release. I think using two branches (develop/master or master/release here) is pretty standard in the corporate world: this workflow is named Gitflow. But that does not mean we have to adopt it @smurfix thoughts? |
|
(It's also surprising that trio was released even though this pull request has not been merged yet) |
|
Huh, I forgot that gitflow actually does this. Reading through some of the posts about it, I think their release branch stuff is designed to support a slow-release workflow, where the mainline development branch isn't always releasable, releases are rare, and each release involves some stabilization ceremony. And also maybe your git repo is your release distribution mechanism, rather than using something like PyPI. That's a valid approach, but I'd rather move more towards a quick-release low-ceremony model (like we discussed some in #220), and the canonical way to get our latest release is to check PyPI, so a |
|
Sounds good 👍 So that means we should close this PR and delete the release branch? (edit: oh, that's waht you said above!) |
|
This has been sitting for a while with no followups, so I guess I'm going to go ahead and do what I said! |
No description provided.